❌ Author of the following commits did not sign a Contributor Agreement:
b2ba60a, 8bb14f6, 638bec8, d1aa8ae, 5d763bf, dd6e46b, 2e0b0cd, e5b4bdc, 5ba5fdb, dc07184, 7000dd7, e804279, dc36dc3, a1ed276, 8d7349e

Please, read and sign the above mentioned agreement if you want to contribute to this project

Preview documentation changes for this PR: https://eui.elastic.co/pr_5114/

Preview documentation changes for this PR: https://eui.elastic.co/pr_5114/

🙌 this is great!

A couple notes from the team sync discussion that push this further:

ID variable naming

It was proposed that we look into a naming convention for these ID variables. The existing documentation guidelines wiki seems like a good place to document this.

Provide additional distinctions to the ID generator

We should explore passing a value to the id generation to further differentiate usages. It probably makes sense in some places and not others, is there a common way to identify these and standardize?

b2ba60a#diff-9c7ad923324bb4de8dc9f3190e7c0e61a86552db898ace382af0f17ac2829755R81

const accordionID__1 = htmlIdGenerator('accordion')();

could become

const accordionID__1 = htmlIdGenerator('accordion')('first');

Create a hook to prevent IDs from changing between renders

Less useful in practice for small instances, but impactful if a component or its usage has a lot of generated IDs, we should cache the generated IDs between renders. The first idea was to use a useState or useRef to do so, but to keep this more readable and less boiler-platey there was an additional suggestion of creating a useEuiHtmlIdGenerator hook (or similar) to wrap the existing service method's functionality but also implementing a react stateful hook to prevent changes.

Create a hook to prevent IDs from changing between renders

Less useful in practice for small instances, but impactful if a component or its usage has a lot of generated IDs, we should cache the generated IDs between renders. The first idea was to use a useState or useRef to do so, but to keep this more readable and less boiler-platey there was an additional suggestion of creating a useEuiHtmlIdGenerator hook (or similar) to wrap the existing service method's functionality but also implementing a react stateful hook to prevent changes.

@constancecchen has started working on a useHtmlGeneratorId hook that can be used in the docs as well. Once PR #5133 is merged, I'll update the code here. We're still open to opinions on the ID variable naming and providing distinctions for the generator function.

Variable naming

My vote is for xAccordionId replacing x with a sort of usage description. A little weird in the examples: exampleAccordionId/firstAccordionId, but should work nice in applications: descriptionAccordionId/faqAccordionId

Distinctions

Primarily for letting human eyes distinguish between these IDs, they are useful in labelling related IDs. https://github.com/elastic/eui/pull/5114/files#diff-5b897b5fbf788b47fa1abebfbfb95f050a2e2f134eb609dccb8167ed3276c423R63 looks like a good case, where the suffix could be used to distinguish between the flyout and title IDs.

Closing this PR because I created four smaller requests to handle this issue. The PRs that were merged to resolve this issue are:
The four pull requests that solve this issue are:

• [Docs] Replace Static HTML Element IDs Generated IDs (Layout Section) #5220 (Layout Section)
• [Docs] Replace Static HTML Element IDs Generated IDs (Nav Section) #5224 (Nav Section)
• [Docs] Replace Static HTML Element IDs Generated IDs (Display Section) #5270 (Display Section)
• [Docs] Replace Static HTML Element IDs Generated IDs (Forms Section) #5279 (Forms Section)